The moment I fell in love with frontend development was the moment I discovered the style.css file in WordPress themes. I could (can!) change a handful of lines and totally change the look and feel of a website—and that, in turn, can alter the way you feel about a piece of writing, make you feel more comfortable buying tickets to an event, or increase the likelihood youʼll share something with your friends. Frontend development is at the intersection of art and logic, business and expression, left brain and right brain, design and nerdery. I love it.

As a job title, “frontend developer” is fairly well-defined and understood. As long as the job is building websites, frontenders are focused on the browser. Even as the job has changed over the decades, we’ve remained browser people. But there’s a pile of new stuff we’re now expected to do, particularly if we’re building a site with a modern JavaScript framework like React, Angular, or Vue.

Though they (and their makers) differ when it comes to syntax and approach, all modern frameworks agree in one critical way: Everything is a component. Even native JavaScript is moving toward its own model of web components. And I like it, this idea of components. You nest and piece them together as needed, which allows you to construct the abstractions that make the most sense for what you’re building. Your card component does all the stuff your real-life card needs to do. Your form component does forms the way your website needs to do forms.

Still, components are a new concept to old developers like me; all this custom component creation has turned me into a site-level architect. Components in JavaScript have taken hold in a way that components on the server side never did. I’ve worked on (and still work on) many a WordPress website where the closest I came was breaking templates into little include() statements. I’ve worked on Ruby on Rails sites with partials that take a handful of local variables. Those are useful for building reusable parts, but they’re a far cry from the robust component models that JavaScript frameworks offer us.

This style of frontend development has really become full-stack development, and components are at the heart of it—so letʼs get into how they work.

Data

Here’s another example: Components that are in charge of displaying content are usually not hard-coded with that content in them. They’re built to be templates, to accept data and construct themselves based on that data. In the olden days, when we were doing this kind of templating, the data had probably already arrived on the page by the time we were working on it. But in a JavaScript-powered app today, it’s more likely that the data is fetched by JavaScript. (Perhaps we fetch it when the component renders.)

In a stack I’m working with right now, the frontend is in React, the API is in GraphQL, and the data is queried through Apollo Client. We use a special hook in the React components to run the queries to fetch the data we need, and another special hook when we need to change that data. Guess who does that work. Is it another category of developer who specializes in data layer work? Nope. This is now part of the domain of frontend development.

All together now

Not only has the to-do list grown longer, but the central questions are also bigger. Should we pick a CMS with an API that will facilitate the kind of frontend building we want to do? Perhaps a headless CMS? Assuming we’re using a JavaScript framework, which one? Why? Can we get a GraphQL API going so we can ask for whatever we need, whenever we need it? Can we statically render this site, even if we’re building with a JavaScript framework? Or server-side render it? Isn’t this important for SEO, speed, and resilience? What are the components we need? A Card, Icon, SearchForm, SiteMenu, Img—can we scaffold these out? Should we start with some kind of design framework on top of the base framework? Should we look at a third-party component library? What’s the client state we might need? How much of this state can be handled at the individual component level, and how much needs to be higher-level? How much of this data can we get at the individual component level, and how much should come down from above? With responsive image syntax, lazy loading, multiple formats, and CDNs to grapple with, how are we going to handle images (the web’s heaviest assets)?

Frontend developers responsible for architecture and data are asking themselves questions that once would have been answered by backend developers. What tools are we going to use for routing? How are we dealing with caching? What about offline support? How is the login/auth system going to work?

Meanwhile, frontend developers more focused on design ask: How much of the styling of this component should be scoped to itself, and how much should come from more global styles? Which styling solutions should we be looking at? Is Sass still the right tool for the job in this new world of components? How can our design be both consistent and supportive of creativity and flexibility?

Most of these questions have rarely, if ever, been asked by frontend developers before now. They also add to the pile of things we were already doing: executing design, semantics, accessibility, and performance. Frontend developers still need to be proficient in HTML, CSS, JavaScript, and how the browser works.

We handle this growing responsibility in different ways. Even though we all technically fall within the same big-tent title, many frontend developers wind up specializing. Often, we don’t have a choice. The term “unicorn” once described the extremely rare person who was good at both frontend and backend development, but these days it’s just as rare to find people skilled at the full spectrum of frontend development. In fact, the term “full stack” has largely come to mean “a frontend developer who does a good amount of the stuff a backend developer used to do.”

We’ve also invented systems to ease the burden. It’s no wonder design systems have taken off in recent years; we’re already building components, so thinking about design in a systematic way is a natural fit. A good design system makes things easier. With design and functionality choices already made, frontend development can focus on composing components—which is still plenty of work, but perhaps less overwhelming.

The web is growing and so are you(r responsibilities)

Being a frontend developer requires an ever-larger grab bag of skills. It’s the natural outcome of the web getting bigger. As more people use the web, as the internet economy expands, and as browsers gain more capabilities and grow more complex, our expectations of what’s possible on the web grow with them.

We’ve already reached a point where most aren’t familiar with the entire growing pile of frontend responsibilities. Many design-focused developers who excel at creative and well-implemented HTML and CSS continue to do well at their jobs, but postings for that kind of role are dwindling. Instead, employers are increasingly looking for developers adept at particular frameworks. Systems-focused developers, as well as entire agencies, specialize in helping other companies build and implement design systems. Data-focused developers feel most at home making data flow through a website—getting hot and heavy with business logic. All of these people might have “frontend developer” on their business cards, but their responsibilities, and even their expectations of their work, might differ greatly, which also impacts the hiring process. In time, I think we’ll find better ways to talk about these distinctions, and companies will get better at spelling out exactly what skills they’re looking for in a frontend developer.

If you feel like you’re falling behind, you’re not alone. Everybody has weak spots, or entire areas they just don’t know the first dang thing about. The good news is that not only can you specialize, you probably should—in fact, you’ll probably end up specializing to some degree whether you plan to or not.

For now, frontend developers have this in common: When we type a <button>, we’re quite literally putting a button into a browser window for users to interact with. When we adjust a color, we’re adjusting exactly what our sighted users see. That’s not so different from a ceramic artist pulling a handle out of clay for a coffee cup. It’s applying craftsmanship to a digital experience.

While backend developers may (and should, and often do) care deeply about a site’s users, they are, as Monica Dinculescu once told me, “outsourcing that responsibility.” We frontend developers take on the role of caring for users most directly. And our users live in a world that’s much bigger than their browsers. They speak different languages. They want different things. They’re trying to solve different problems. They have different abilities. They have different levels of urgency. They’re also why we build things at all. They’re who I’m trying to impress with my mad CSS skills. Who I’m trying to get to buy my widget. Who my business charts hinge upon. Whose reaction can sway my emotions like yarn in the breeze.

Being a frontend developer puts us between the thing we’re building and the people we’re building it for—and that’s a place some of us really enjoy being, even if it means taking on ever-larger bundles of responsibility from that big haystack of work. Weighty stuff, isn’t it?